cc @Firewall @slemeur (screenshot and details are available at #417)

Can we work on the colors, please? They're not contrasty enough.

Thanks @adameska for your contribution and the suggestion. I really do like the idea and think it'll help the experience.
+1 on my side for the PR

pnpm format:check is failing on CI, you will need to run pnpm format:fix to fix
I can see there is also a few fixes to do to make pnpm lint:check pass

pnpm format:check is failing on CI, you will need to run pnpm format:fix to fix I can see there is also a few fixes to do to make pnpm lint:check pass

Thank you! I saw something about prettier and was trying to run that to fix it but that wasn't taking...

Ok, i fixed the linting issues. We've also been migrating over to structured logging which looks horrible in podman so I attempted to make those look better... once this PR gets complete if advisable i wouldn't mind adding a sidebar when structured logging was detected to show the values in a nice table.

Ok, i fixed the linting issues. We've also been migrating over to structured logging which looks horrible in podman so I attempted to make those look better... once this PR gets complete if advisable i wouldn't mind adding a sidebar when structured logging was detected to show the values in a nice table.

The feature is interesting, but I'm afraid it will be very cpu-consuming if it enabled for all containers. I think it would be interesting for the user to select which format to use for each container. @slemeur WDYT?

Ok, i fixed the linting issues. We've also been migrating over to structured logging which looks horrible in podman so I attempted to make those look better... once this PR gets complete if advisable i wouldn't mind adding a sidebar when structured logging was detected to show the values in a nice table.

The feature is interesting, but I'm afraid it will be very cpu-consuming if it enabled for all containers. I think it would be interesting for the user to select which format to use for each container. @slemeur WDYT?

I didn't consider the cpu much. I feel like it should be ok but I could just parse the first 10 rows and if 9 of them have recognizable json then enable it if it seems fast enough when I test it with a 10k long file. I don't like the idea of having users enter their logging format since a lot of our applications use different ones.

hello, maybe bring an option to enable this feature. So it's an option people can turn on or off. The most difficult part would be to choose the default behavior.

hello, maybe bring an option to enable this feature. So it's an option people can turn on or off. The most difficult part would be to choose the default behavior.

I have the JSON colorization not wired up by default (just added all the code for it for now). An option seems like a good idea although not sure how to add that outside of the toolbar i added in the other PR. I think for now this only coloring log level is minimal enough that it shouldn't offend people i hope...

I did locally enable coloring all json for a container with a ton of json log lines and it loaded up instantly for me so i'm not at all concerned about performance personally... but something you guys could test and let me know.

Let me know how you want to proceed. IMO just completing this PR as is (only coloring log level for now but adding the code for JSON coloring to be wired up from options) should be safe enough and hopefully provide value as is.

In this PR, I would suggest to include the code for the non-JSON colorization only, and keep the JSON-related code for another PR, when it can be activated.

You may have an option at the extension level, so the user could choose between text and JSON colorization, for all containers. It is not very realistic, as all containers are not always using the same log format, but that would be a first step to be able to test the JSON one.
You can see how to declare such configuration in the podman extension for example: https://github.com/podman-desktop/podman-desktop/blob/main/extensions/podman/packages/extension/package.json#L49
and access the value using the extension api: https://github.com/podman-desktop/podman-desktop/blob/main/packages/extension-api/src/extension-api.d.ts#L1219

In this PR, I would suggest to include the code for the non-JSON colorization only, and keep the JSON-related code for another PR, when it can be activated.

You may have an option at the extension level, so the user could choose between text and JSON colorization, for all containers. It is not very realistic, as all containers are not always using the same log format, but that would be a first step to be able to test the JSON one. You can see how to declare such configuration in the podman extension for example: https://github.com/podman-desktop/podman-desktop/blob/main/extensions/podman/packages/extension/package.json#L49 and access the value using the extension api: https://github.com/podman-desktop/podman-desktop/blob/main/packages/extension-api/src/extension-api.d.ts#L1219

I'm going to push hard against users picking one or the other. It's easy to detect if a file is logged in json/structure logging format so we can detect and process if that's the case. IMO the only thing the user should be able to pick is a color theme potentially and colorizing logs at all on/off. I will put the Json coloring in a separate PR but that will be dependent on this PR

Sorry, there was a problem on the pnpm-lock file. The problem should be fixed on main, You'll need to rebase so I can run the ci again

I can see some characters which should not be displayed:

glad you tested that case (mine have err) i had a typo. Should be fixed now! I also thought i deleted the json files but guess i never synced those. Hopefully this is good to go now.